Add support for help-char being a generalized input event

Add support for help-char being a generalized input event

Not all keyboard events can be represented as a character. For example,
while ?\C-h is a character, represented as 8 in decimal, C-M-h is
represented by 134217736 in decimal, as can be obtained from:

(elt (kbd "C-M-h") 0)

It is useful to allow help-char to be set to something other than a
character, as characters cover only a very small region of possible
input events. This is especially important because help-char is used to
bring up the pagination menu (when which-key-use-C-h-commands is t), and
this won't work if it conflicts with any keybinding within the prefix
command that led to the activation of which-key.

If help-char is left set to ?\C-h things work fine because as a
convention keymaps avoid binding that due to it being the default
binding for help. That is just a convention, however, and things become
more difficult with a heavily user-customized set of keybindings that
preclude the use of ?\C-h for that purpose.

In that case, if ?\C-h cannot be used, it is much easier to find a
binding for help-char that is unlikely to conflict with any bindings if
it is permitted to use the full range of modifier keys.

This patch modifies which-key--next-page-hint, which is the only place
that broke when I set help-char to a keyboard event that wasn't a
character. Rather than doing a string comparison, help-char and prefix
keys are put in vectors and equality is checked that way.